IBIS Macromodel Task Group Meeting date: 17 November 2020 Members (asterisk for those attending): Achronix Semiconductor * Hansel Dsilva ANSYS: * Curtis Clark * Wei-hsing Huang Cadence Design Systems: Ambrish Varma Ken Willis * Jared James Google: Zhiping Yang Intel: * Michael Mirmak Kinger Cai Alaeddin Aydiner Keysight Technologies: * Fangyi Rao * Radek Biernacki Ming Yan Todd Bermensolo Rui Yang Luminous Computing * David Banas Marvell Steve Parker Mentor, A Siemens Business: * Arpad Muranyi Micron Technology: * Randy Wolff * Justin Butterfield SAE ITC Jose Godoy SiSoft (Mathworks): * Walter Katz Mike LaBonte Teraspeed Labs: * Bob Ross Zuken USA: * Lance Wang The meeting was led by Arpad Muranyi. Curtis Clark took the minutes. -------------------------------------------------------------------------------- Opens: - David Banas reintroduced himself. He had attended in the past while a member of Altera and eASIC. Arpad noted David's work on open-source IBIS-AMI related tools and asked him to give a short description/overview of them to the group. David said that he has public-domain open-source tools on GitHub. These include infrastructure for AMI model creation, a python tool for wrapping AMI .dlls and allowing them to be exercised and tested from python, and a serial link simulator and design tool that can use IBIS AMI models for Tx and Rx. Arpad suggested David send out links to these tools. David took an AR to do so. - Arpad's agenda noted the upcoming meetings during the holiday season. It suggested the meetings be cancelled for November 24th, December 22nd, and December 29th. Radek moved to cancel those 3 meetings. Curtis seconded. There were no objections. Our next meeting will be December 1st. ------------- Review of ARs: - None. -------------------------- Call for patent disclosure: - None. ------------------------- Review of Meeting Minutes: Arpad asked for any comments or corrections to the minutes of the November 10th meeting. Michael moved to approve the minutes. Walter seconded the motion. There were no objections. ------------- New Discussion: DDR6x: Randy said he is still gathering data and may have more on this topic at the next meeting. PI Modeling in IBIS: Arpad noted that Zhiping had sent an email to the ATM list saying that he could not attend. Arpad suggested people reply to Zhiping's email if they have any questions about this topic. Redriver Flow Issues: Based on the previous week's meeting and emails, Arpad suggested it might help to create a list of which combinations of Init-Only, GetWave-Only, and Dual models are easy, hard, or impossible to support. He thought having such a list might facilitate discussion and decisions. The fundamental question is how do we deal with the problematic combinations, or do we decide to prohibit them? Once we make those decisions, we can figure out how to change the specification. Walter noted that he had sent two versions of a "New Reliable AMI Flows" document last week, and he had a third version to review in the meeting. Walter said there are certain combinations of Init-Only, GetWave-Only, and Dual models that are problematic. For a simple, single-channel, Tx to Rx, there are 9 possible combinations. One that's problematic is when the Tx is GetWave-Only and the Rx is Init-Only. A second complication occurs because our flows support Tx Init functions that optimize themselves based on their downstream channels. This is problematic for a number of reasons, and he proposed that we could enhance the standard or just create a list of recommendations that model makers to do things a certain way. The first suggestion is to make all models Dual. The exception is a terminal Rx or retimer Rx can be GetWave-Only. Walter suggested that there should never be an Init-Only model. If the model maker can create the Init function, then it should be trivial for them to make a GetWave function that applies the same equalization. An EDA tool trying to generate a pseudo-GetWave may rely on deconvolution or something which is numerically problematic. Michael noted his disagreement with the assertion that Init-Only models are never necessary but said we could discuss that later. Walter said that things get much simpler if Tx models don't adapt based on their input IR. Only Rx models adapt, and they have the input IR and adapt their CTLE and AGC and FFE, etc., but Tx models don't adapt, and they just apply their equalization. In the case of a primary Tx, it applies its equalization to a unit IR. In the case of a redriver, the Tx applies its equalization to the output of the redriver's Rx. It's an unnatural act for Tx hardware to know about the downstream channel. It was a cute idea originally to allow a Tx model to optimize based on the downstream channel, but we now know that it's proven to be not very useful in modeling. Fangyi confirmed/emphasized the two assumptions Walter was making. First, all models are dual, except the terminal Rx could be GetWave-Only or Dual (Note: a retimer Rx could be considered a terminal Rx in this sense). Second, the assumption is that Tx Inits do not adapt, as expressed in this function in Walter's document: UpstreamIR * txInit(DownstreamIR) = DownstreamIR * txInit(UpstreamIR) note: * = convolution note: this equation also describes Init_Is_Commutative=true Walter agreed that these were the assumptions. Fangyi asked for confirmation that the H1, H2, and H3 referred to that individual IRs of the "analog channels". Walter agreed and said they represent the IRs of each channel along with the impedances of the Tx and Rx connected to it. Given these assumptions, Walter's document shows the Init flow for the redriver chain becomes a simple daisy chain of convolution operations. It becomes identical to the GetWave flow, with IRs replacing the waveforms. Arpad returned to his original question about problematic combinations and how we could address them in the specification. He asked if all the problem cases would be eliminated if we make the restriction that Tx Init functions should not adapt. Fangyi said this was not sufficient, and that we also need the first assumption that all models are Dual, except the Terminal Rx can be GetWave-only. Fangyi also emphasized that the terminal Rx cannot be Init-Only. With these restrictions, the existing flow in the specification works fine. Walter agreed. Walter explained why every model upstream of the final Rx must have an Init that returns an impulse. Some terminal Rx models do some of their equalization setup during Init, even though they don't return an IR. These models may then do additional equalization optimization in the time domain flow. He noted, for example, that it's really hard to do CTLE optimization in time domain. Fangyi emphasized one assumption in Walter's document that is a key difference from the current specification. In the current flow for redrivers, the Rx Init only gets the IR back to its nearest upstream Tx. In Walter's proposal the IR passed to an Rx includes everything upstream (entire path back to the initial Tx). Walter reviewed page 264 of IBIS 7.0 and confirmed Fangyi was correct about the current flow (Note: Walter's BIRD166 proposal was originally created to address the issue Fangyi described). Fangyi said the purpose of Walter's proposed new "everything upstream IR" is to allow the terminal Rx to optimize based on the entire channel, and a condition of being able to use the entire upstream channel IR is that every upstream model has to have a GetWave. Walter agreed but noted that it's not quite a requirement that every upstream model is Dual. He said that in a chain from initial Tx to final Rx, the initial models can be Init-Only, up until you hit the first model that has a GetWave. That is, what you can't allow is an Init-Only model to appear downstream of the first model that contains a GetWave. These combinations are explained in Walter's document. Fangyi agreed, but said "why bother?" when we can just state that the models should be Dual. Walter agreed that he would prefer to state that models should be Dual. Walter said we all agree that the current redriver flow is fatally flawed, since the terminal Rx does not get the full upstream channel IR. Walter noted that Michael had some reservations about the idea that an Init-Only model can be trivially turned into a Dual model. Wei-hsing agreed that theoretically any Init-Only model can be extended by the model maker to include GetWave. However, he noted that this is putting extra work on the model maker, and implementing GetWave may include non-trivial software issues such as dealing with the multi-block waveform data in a GetWave simulation. He said that in some common scenarios the EDA tool could provide a pseudo-GetWave instead of the model maker providing GetWave. For example, for a Tx Init-Only model that does not adapt and is fully LTI (i.e., the scenario Walter described with the Init_Is_Commutative parameter in the second version of his document), the EDA tool could reliably create a pseudo-GetWave without resorting to deconvolution or numerically problematic methods. Walter recalled that three years ago he had asked David to publish a GetWave function that took an impulse response filter used in an Init function. This GetWave function convolves the filter response with the input waveform to create the output waveform, and it includes all the boilerplate to deal with multiple blocks and overlap. Since David had in fact published this function in the public domain, it was available to any model maker. So, Walter said there is no real excuse for creating an Init-Only model, since converting it to a Dual model is a straightforward exercise. Arpad said we need to make sure any restrictions on types of models (e.g., Init- Only) are carefully worded so that we don't exclude people from making their preferred models. Walter said we didn't have to restrict the types of models, but we could say that if someone makes Init-Only or GetWave-Only models there are flows that don't work. Fangyi said we should hear Michael and Ambrish's thoughts on Init-Only models. Walter took an AR to send out the document we'd reviewed in the meeting. - Walter: Motion to adjourn. - Curtis: Second. - Arpad: Thank you all for joining. AR: Walter to send the new version of "New Reliable AMI Flows" to the ATM list. AR: David to send the links to his public domain tools to the ATM list. ------------- Next meeting: 01 December 2020 12:00pm PT ------------- IBIS Interconnect SPICE Wish List: 1) Simulator directives